feat(inbox): Dismiss reports with feedback by Twixes · Pull Request #2053 · PostHog/code

Twixes · 2026-05-06T08:12:23Z

Problem

"Snooze", "Suppress" and "Delete" don't provide us with info on why the user got rid of the report – and it's hard to understand how to use them.

Changes

Replacing those three buttons with one clear "Dismiss", and a hidden dropdown for "Delete" - as well as "Reingest".

Basically replaces the old suppress-confirmation dialog and adds a "Dismiss" button (with thumbs-down icon) to both the inbox toolbar and the report detail pane header. Notes:

When a single report is selected, the Dismiss button opens a dialog that captures why the report is being dismissed — single choice plus an optional note.
- Multi-select (2+) keeps the previous bulk Snooze / Suppress buttons without the dialog. For mass management.
Toolbar actions reorganized: Delete and dev-only Reingest moved into a ⋯ overflow menu, keeping the primary toolbar clean.

Implementation PR link now shown in the report detail header next to "Dismiss" (so they function as "here's the PR to review, accept or dismiss").

Backend prerequisite PR: PostHog/posthog#57768

Created with PostHog Code

Add a Suppress button to the top of the report detail pane and replace the bulk-suppress confirmation in the toolbar with a dialog that asks why the user is suppressing. The dialog offers six radio reasons plus an optional free-form note. Selections are sent alongside the state transition and persisted server-side as a `dismissal`-type report artefact so the rationale survives status changes and can stack over time. Generated-By: PostHog Code Task-Id: d3d675ab-707a-4a35-939b-9a9ab0f5c5b5

Replace SuppressDialog with DismissReportDialog owned by InboxSignalsTab; derive dismissal options from shared dismissalReasons. Toolbar shows Dismiss (≤1 selected, opens modal) or Snooze+Suppress (>1 selected, direct bulk actions). Remove list hover dismiss control; use gray soft buttons for dismiss-related actions. Tighten bulk suppress/snooze eligibility and keep legacy reason parsing.

…lbar Puts secondary bulk actions behind a ⋯ menu (inbox-tweaks pattern), keeps Snooze/Suppress/Dismiss as primary actions, and preserves the shared dismiss dialog and existing delete confirmation AlertDialog.

… tasks hook Keep dismissal constants/types on @shared/dismissalReasons only; use DismissalReason from there in artefact types. Extract useReportTasks/getTaskPrUrl to an inbox hook, dedupe overflow menu rows via BulkOverflowMenuItem, unify dismiss mutation pending for toolbar and detail, and trim ExplainedLabel exports. Inline dismissal radio parsing in DismissReportDialog.

greptile-apps · 2026-05-07T13:19:47Z

Comments Outside Diff (1)

apps/code/src/renderer/features/inbox/components/DismissReportDialog.tsx, line 165-168 (link)

Misleading feedback copy for the snooze path

The dialog body tells the user "Your feedback is saved on the report and helps the agents do better", but when "Already fixed" is selected the handler calls snoozeSelected() with no payload — and the API comment explicitly says dismissal_reason/dismissal_note are "Only honored when state == 'suppressed'". So the chosen reason and any note the user typed are silently discarded on this path. The copy should either be conditioned on the selected reason, or the "already fixed" path should be excluded from the blanket feedback promise.

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/code/src/renderer/features/inbox/components/DismissReportDialog.tsx
Line: 165-168

Comment:
**Misleading feedback copy for the snooze path**

The dialog body tells the user "Your feedback is saved on the report and helps the agents do better", but when "Already fixed" is selected the handler calls `snoozeSelected()` with no payload — and the API comment explicitly says `dismissal_reason`/`dismissal_note` are "Only honored when state == 'suppressed'". So the chosen reason and any note the user typed are silently discarded on this path. The copy should either be conditioned on the selected reason, or the "already fixed" path should be excluded from the blanket feedback promise.

How can I resolve this? If you propose a fix, please make it concise.

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
apps/code/src/renderer/features/inbox/components/DismissReportDialog.tsx:165-168
**Misleading feedback copy for the snooze path**

The dialog body tells the user "Your feedback is saved on the report and helps the agents do better", but when "Already fixed" is selected the handler calls `snoozeSelected()` with no payload — and the API comment explicitly says `dismissal_reason`/`dismissal_note` are "Only honored when state == 'suppressed'". So the chosen reason and any note the user typed are silently discarded on this path. The copy should either be conditioned on the selected reason, or the "already fixed" path should be excluded from the blanket feedback promise.

### Issue 2 of 2
apps/code/src/renderer/features/inbox/hooks/useInboxBulkActions.ts:21-29
**Active-state reports can no longer be dismissed**

`"potential"`, `"candidate"`, and `"in_progress"` were removed from `suppressibleStatuses`, so the Dismiss button in `ReportDetailPane` will be permanently disabled for reports that are actively being processed. Previously a user could suppress a report at any active stage; now they must wait until the report reaches `failed`, `pending_input`, or `ready`. If that narrowing is intentional it should be documented (a comment on the set or a note in the tooltip), otherwise it will silently block early rejections.

_{Reviews (1): Last reviewed commit: "Simplify" | Re-trigger Greptile}

greptile-apps · 2026-05-08T07:22:07Z

Comments Outside Diff (1)

apps/code/src/renderer/features/inbox/components/list/SignalsToolbar.tsx, line 1019-1028 (link)

Reingest action exposed to all environments

The IS_DEV import was removed and the Reingest menu item is now shown unconditionally to every user. Previously the button was gated with IS_DEV && (...) and labelled "DEV-ONLY". The PR description still refers to it as "dev-only Reingest", so this appears to be an unintentional regression — all production users will now see and be able to trigger a reingest.

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/code/src/renderer/features/inbox/components/list/SignalsToolbar.tsx
Line: 1019-1028

Comment:
**Reingest action exposed to all environments**

The `IS_DEV` import was removed and the Reingest menu item is now shown unconditionally to every user. Previously the button was gated with `IS_DEV && (...)` and labelled "DEV-ONLY". The PR description still refers to it as "dev-only Reingest", so this appears to be an unintentional regression — all production users will now see and be able to trigger a reingest.

How can I resolve this? If you propose a fix, please make it concise.

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
apps/code/src/renderer/features/inbox/components/list/SignalsToolbar.tsx:298-303
The `singleDismissDisabledReason` concatenation produces duplicate text. Because `snoozeDisabledReason` and `suppressDisabledReason` are now both derived from the same `getSnoozeOrSuppressDisabledReason` function, they are always identical strings. The ternary therefore always resolves to either `null` (both are null) or `"reason · reason"` (both non-null with the same value) — the middle case where only one is non-null can never occur. The user would see a doubled tooltip such as `"all selected reports must be ready to dismiss · all selected reports must be ready to dismiss"`.

```suggestion
  const singleDismissDisabledReason =
    selectedCount === 0 ? snoozeDisabledReason : snoozeDisabledReason;
```

### Issue 2 of 2
apps/code/src/renderer/features/inbox/components/list/SignalsToolbar.tsx:1019-1028
**Reingest action exposed to all environments**

The `IS_DEV` import was removed and the Reingest menu item is now shown unconditionally to every user. Previously the button was gated with `IS_DEV && (...)` and labelled "DEV-ONLY". The PR description still refers to it as "dev-only Reingest", so this appears to be an unintentional regression — all production users will now see and be able to trigger a reingest.

_{Reviews (2): Last reviewed commit: "Fix modal button color" | Re-trigger Greptile}

## Problem PostHog Code will surface a "Dismiss" dialog on the inbox where a reviewer can mark a report as not worth acting on, as of PostHog/code#2053. We need to record "why" alongside the status change so we can: - distinguish "already fixed" from "wontfix" - stack multiple dismissals over time when a report is unsnoozed and later re-dismissed for a different reason The existing `state` action only flips a status flag and offers no place to attach this metadata. ## Changes Adding a new `dismissal` value on `SignalReportArtefact.ArtefactType`. `POST /api/projects/:team_id/signals/reports/:id/state/` now accepts two optional body fields: - `dismissal_reason`- Arbitrary string code. The set of valid codes is owned by PostHog Code, so we can iterate there without a backend change. - `dismissal_note` - Free-form text, capped at 4000 characters. When either is provided and the target state is `suppressed` **or** `potential`, the action creates a `dismissal` artefact alongside the status change capturing reason, note, and the dismissing user's ID. Important note: Reingestion is now available to all users. We need it e.g. to let people re-run failed research, which we've gotten reports about in Discord. ### Why an artefact rather than a column on the report The existing `SUPPRESSED` status is a single flag. We need history (the same report can be dismissed multiple times for different reasons over its lifetime), and a typed artefact matches the existing pattern for everything else attached to a report. ## How did you test this code? `TestSignalReportSuppressionAPI` ## Publish to changelog? no

Twixes mentioned this pull request May 6, 2026

feat(signals): Record dismissal feedback as report artefact PostHog/posthog#57768

Merged

Twixes changed the title ~~feat(inbox): suppress dialog with dismissal feedback~~ feat(inbox): Dismiss reports with feedback May 7, 2026

Twixes added 5 commits May 7, 2026 10:35

feat(inbox): overflow menu for delete and dev reingest on Signals too…

b1f9262

…lbar Puts secondary bulk actions behind a ⋯ menu (inbox-tweaks pattern), keeps Snooze/Suppress/Dismiss as primary actions, and preserves the shared dismiss dialog and existing delete confirmation AlertDialog.

Simplify

87aae54

Tweak wording

5abe650

Twixes requested a review from a team May 7, 2026 11:14

Allow everyone to reingest

c008f81

Twixes marked this pull request as ready for review May 7, 2026 13:16

greptile-apps Bot reviewed May 7, 2026

View reviewed changes

Comment thread apps/code/src/renderer/features/inbox/hooks/useInboxBulkActions.ts Outdated

Twixes added 2 commits May 7, 2026 16:36

Simplify

b2aa08e

Fix modal button color

f9c8547

andrewm4894 approved these changes May 8, 2026

View reviewed changes

Twixes merged commit 2b3e6c5 into main May 10, 2026
15 checks passed

Twixes deleted the posthog-code/suppress-dialog-with-dismissal-feedback branch May 10, 2026 16:21

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(inbox): Dismiss reports with feedback#2053

feat(inbox): Dismiss reports with feedback#2053
Twixes merged 9 commits into
mainfrom
posthog-code/suppress-dialog-with-dismissal-feedback

Twixes commented May 6, 2026 •

edited

Loading

Uh oh!

greptile-apps Bot commented May 7, 2026 •

edited

Loading

Comments Outside Diff (1)

Uh oh!

Uh oh!

greptile-apps Bot commented May 8, 2026 •

edited

Loading

Comments Outside Diff (1)

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

Twixes commented May 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Changes

Uh oh!

greptile-apps Bot commented May 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Comments Outside Diff (1)

Uh oh!

Uh oh!

greptile-apps Bot commented May 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Comments Outside Diff (1)

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Twixes commented May 6, 2026 •

edited

Loading

greptile-apps Bot commented May 7, 2026 •

edited

Loading

greptile-apps Bot commented May 8, 2026 •

edited

Loading